home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 7 < prev    next >
Text File  |  1996-08-06  |  2KB  |  44 lines
  1. Newsgroups: comp.std.c
  2. Path: vixen.cso.uiuc.edu!uchinews!news
  3. From: Michael Spertus<mps@geodesic.com>
  4. Subject: Re: Alignment of malloc()
  5. X-Nntp-Posting-Host: ford.uchicago.edu
  6. Message-ID: <DKKHCH.L6r@midway.uchicago.edu>
  7. Sender: news@midway.uchicago.edu (News Administrator)
  8. Organization: Dept. of Mathematics
  9. References: <DKDA7D.Kw7@midway.uchicago.edu> <j66Sx*FRe@yaps.rhein.de>
  10. Date: Tue, 2 Jan 1996 18:43:28 GMT
  11.  
  12. In article <j66Sx*FRe@yaps.rhein.de>,
  13. Arno Eigenwillig <arno@yaps.rhein.de> wrote:
  14. >
  15. >That is a quality-of-implementation issue and hence beyond the scope
  16. >of The Standard. All The Standard defines in the end is the output a C
  17. >program creates, not the timing nor (thanks to the as-if rule) the way
  18. >it creates it.
  19. >
  20. My question is what the committee means by the words "proper alignment". If
  21. "proper" COMPLETELY ignores efficiency consideration even if they are
  22. gross, it means that I would have to align all malloc() returns according to
  23. the size of the data in all portable code I write. However, I've never seen
  24. an "ANSI C" textbook that advises aligning malloc() returns by hand. So
  25. the interpretation that completely ignores reasonable efficiency expectations
  26. is incompatible with the way people are taught to code portably in C.
  27.  
  28. For this reason, the two possibilities are:
  29.  
  30. 1) All the texts (including K & R) are advocating code that is not reasonable
  31. on (the most common) compliant implementations of C.
  32.  
  33. or
  34.  
  35. 2) 32 bit alignment of malloc() on PCs is not compliant.
  36.  
  37. Either possibility is very serious, and violates assumptions that most 
  38. programmers take for granted
  39.  
  40.  
  41. Regards,
  42.  
  43. Mike
  44.